现代源代码控制系统提供了强大的工具，使创建源代码分支变得容易。但最终这些分支必须合并回来，许多团队花费大量时间来处理他们错综复杂的树状分支。有一些模式可以使团队有效地使用分支，集中于整合多个开发人员的工作并组织通往生产发布的路径。总的主题是分支应该经常集成，并将精力集中在健康的基线上，该基线可以轻松部署到生产环境中。

发布/展示/询问是一种分支策略，它结合了拉取请求的功能以及持续发布更改的能力。更改被归类为发布（合并到主线，无需审查）、展示（打开拉取请求以供审查，但立即合并到主线）或询问（打开拉取请求以供讨论，然后再合并）。

“通过抽象进行分支”是一种技术，用于以渐进的方式对软件系统进行大规模更改，使您能够在更改仍在进行中时定期发布系统。

持续交付是一种软件开发纪律，您以这样一种方式构建软件，即软件可以随时发布到生产环境中。

当您执行持续交付时

• 您的软件在其整个生命周期中都是可部署的
• 您的团队优先考虑保持软件的可部署性，而不是开发新功能
• 任何人都可以随时获得关于其系统生产就绪性的快速、自动化的反馈，无论何时有人对它们进行更改
• 您可以按需对软件的任何版本执行一键式部署到任何环境

回归错误是在软件中出现的新错误，这些错误在一段时间内一直存在。在寻找它们时，通常有价值的是找出软件中的哪个更改导致它们出现。查看该更改可以提供关于错误在哪里以及如何消除它的宝贵线索。这种调查形式没有一个众所周知的术语，但我称之为差异调试。

功能分支是一种源代码分支模式，开发人员在开始开发新功能时会打开一个分支。她在该分支上完成所有功能工作，并在功能完成后将更改与团队的其余部分集成。

软件开发团队发现，如果他们能尽可能频繁地集成他们的工作，生活会变得容易得多。他们还发现，频繁发布到生产环境中很有价值。但团队不希望将半开发的功能暴露给用户。处理这种紧张局势的一个有用技术是构建所有后端代码，进行集成，但不构建用户界面。该功能可以集成和测试，但 UI 会被保留到最后，就像一块关键石一样，它被添加到功能中以完成功能，向用户展示它。

我最近用 Mercurial 压制了一些提交，所以我想值得发一篇帖子，以防其他人也想要这样做。我不知道这是否是最好的方法，但对我来说似乎很有效。

作为一个经常使用版本控制的人，我认为它可以扩展到更多计算机使用的领域。除了软件开发人员之外，很少有计算机用户使用版本控制。然而，正如软件开发人员所知，版本控制是协作工作的一种很好的机制，它允许多个人共同开发一个软件系统。版本控制更广泛地使用会带来什么好处呢？

我非常喜欢持续集成，它是一种相对简单的实践，可以为大多数开发团队带来巨大的改变。然而，就像大多数实践一样，它也有其缺陷^H^H^H^H^H改进的机会。Paul Duvall，该主题即将成为标准书籍的作者，指出了其中之一。如果提交构建失败，整个团队都会受到影响，并且可能在修复之前减速。

最近苹果宣布了时光机，它能够回到过去，查看您所有文件的更改，包括查找已删除的文件。对于我们中的一些狂热爱好者来说，这不是一个新功能。像其他人一样，我把我的整个工作目录放在版本控制下，最初是 CVS，现在是Subversion，因此一直能够轻松查看我所做的一切工作的更改。这是一个如此有用的功能，我之前就想过拥有更多版本控制会是什么样子，也许时光机是朝着这个方向迈出的一步。

持续集成的支持者普遍认为构建应该是可重复的。我们的意思是，在任何时候，您都应该能够获取正在使用的系统的某个旧版本，并以与当时完全相同的方式从源代码构建它。

那些听到我和同事谈论功能分支的人都知道我们不是这种模式的忠实粉丝。我们反对的一个重要部分是，分支很容易，但合并很难。我们偶尔会听到的一种论点是，现代版本控制工具使合并变得足够容易，因此功能分支是值得的。

大多数版本控制系统依赖于使用和理解工件版本之间的更改 - 通常被称为来自可以在 Unix 中生成它们的命令的差异。好的差异（和合并）算法适用于文本和二进制文件。这些差异的问题在于它们相当愚蠢。它们所做的只是查看两个工件版本并生成一种从一个版本到另一个版本的方法。

Subversion 是一个开源版本控制系统 - 本质上是 CVS 的继任者。它修复了 CVS 中最大的问题，引入了原子提交和对文件和目录重命名的支持。我已经使用它几年了，发现它非常可靠。

当我讨论版本控制工具时，我说这是一个非科学的意见集合。当我这样做的时候，我意识到我可以通过进行调查，在我的分析中添加一些虚假但迷人的数字。Google 的电子表格使进行调查的机制变得非常简单，所以我无法抗拒。

如果您花时间与软件开发人员谈论工具，我听到的最热门话题之一就是版本控制工具。一旦您开始使用版本控制工具，任何有能力的开发人员都会这样做，那么它们就会成为您生活中不可或缺的一部分。版本工具不仅对维护项目的历史很重要，而且也是团队协作的基础。因此，我经常听到关于糟糕的版本控制工具的抱怨也就不足为奇了。在我们最近的Thoughtworks 技术雷达中，我们指出了两个企业应该评估以供使用的版本控制工具：Subversion 和分布式版本控制系统 (DVCS)。在这里，我想扩展一下，总结一下我们在内部关于版本控制工具的许多讨论。